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Service Models Explained 
Abstract 


The IETF has produced many modules in the YANG modeling language. 
The majority of these modules are used to construct data models to 
model devices or monolithic functions. 


A small number of YANG modules have been defined to model services 
(for example, the Layer 3 Virtual Private Network Service Model 
(L3SM) produced by the L3SM working group and documented in RFC 
8049). 


This document describes service models as used within the IETF and 
also shows where a service model might fit into a software-defined 
networking architecture. Note that service models do not make any 
assumption of how a service is actually engineered and delivered for 
a customer; details of how network protocols and devices are 
engineered to deliver a service are captured in other modules that 
are not exposed through the interface between the customer and the 
provider. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8309. 


Wu, et al. Informational [Page 1] 


RFC 8309 Service Models Explained 


Copyright Notice 


January 2018 


Copyright (c) 2018 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 


(https://trustee.ietf.org/license-info) 
publication of this document. 
carefully, 
to this document. 


in effect on the date of 
Please review these documents 

as they describe your rights and restrictions with respect 
Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Table of Contents 


1. Introduction ; 
2. Terms and Concepts 
3. Using Service Models . 
3.1. Practical Considerations 
4. Service Models in an SDN Context 
5. Possible Causes of Confusion 
6. Comparison with Other Work A 
6.1. Comparison with Network Service Models- 
6.2. Service Delivery and Network Element Model Work 
6.3. Customer Service Model Work 
6.4. The MEF Architecture 
7. Further Concepts : 
7.1. Technology Agnostic 
7.2. Relationship to Policy 
7.3. Operator-Specific Features 
7.4. Supporting Multiple Services 
8. Security Considerations 
9. Manageability Considerations 
10. IANA Considerations 
11. References ae a ate 
11.1. Normative References 
11.2. Informative References 
Acknowledgements 


Authors’ Addresses 


Wu, et al. Informational 


[Page 2] 


RFC 8309 Service Models Explained January 2018 


Le 


Wu, 


Introduction 


In recent years, the number of modules written in the YANG modeling 
language [RFC6020] for configuration and monitoring has blossomed. 
Many of these are used for device-level configuration (for example, 
[RFC7223]) or for control of monolithic functions or protocol 
instances (for example, [RFC7407]). 


[RFC7950] makes a distinction between a "data model", which it 
defines as describing how data is represented and accessed, and a 
"YANG module", which defines hierarchies of schema nodes to make a 
self-contained and compilable block of definitions and inclusions. 
YANG structures data models into modules for ease of use. 


Within the context of Software-Defined Networking (SDN) [RFC7149] 
[RFC7426], YANG data modules may be used on the interface between a 
controller and network devices, as well as between network 
orchestrators and controllers. There may also be a hierarchy of such 
components with super controllers, domain controllers, and device 
controllers all exchanging information and instructions using YANG 
modules. 


There has been interest in using YANG to define and document data 
models that describe services in a portable way that is independent 
of which network operator uses the model, for example, the Layer 3 
Virtual Private Network Service Model (L3SM) [RFC8049]. Such models 
may be used in manual and even paper-driven service request processes 
with a gradual transition to IT-based mechanisms. Ultimately, they 
could be used in online, software-driven dynamic systems and may be 
used as part of an SDN system. 


This document explains the scope and purpose of service models within 
the IETF (and is limited to within the scope of the IETF) and 
describes how a service model can be used by a network operator. 
Equally, this document clarifies what a service model is not and 
dispels some common misconceptions. 


The document also shows where a service model might fit into an SDN 
architecture, but it is important to note that a service model does 
not require or preclude the use of SDN. Note that service models do 
not make any assumption of how a service is actually engineered and 
delivered to a customer; details of how network protocols and devices 
are engineered to deliver a service are captured in other modules 
that are not exposed through the interface between the customer and 
the provider. 
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In summary, a service model is a formal representation of the data 
elements that describe a network service as that service is described 
to or requested by a customer of a network operator. Details 
included in the service model include a description of the service as 
experienced by the customer, but not features of how that service is 
delivered or realized by the service provider. 


Other work on classifying YANG modules has been done in [RFC8199]. 
That document provides an important reference for this document and 
also uses the term "service module". In this document, Section 6.1 
provides a comparison between these two uses of the same terminology. 


Terms and Concepts 


Readers should familiarize themselves with the description and 
classification of YANG modules provided in [RFC8199]. 


The following terms are used in this document: 


Network Operator: This term is used to refer to the company that 
owns and operates one or more networks that provide Internet 
connectivity services and/or other services. 


Customer: This term refers to someone who purchases a service 
(including connectivity) from a network operator. In the context 
of this document, a customer is usually a company that runs their 
own network or computing platforms and wishes to connect to the 
Internet or between sites. Such a customer may operate an 
enterprise network or a data center. Sometimes this term may also 
be used to refer to the individual in such a company who contracts 
to buy services from a network operator. A customer as described 
here is a separate commercial operation from the network operator, 
but some companies may operate with internal customers so that, 
for example, an IP/MPLS packet network may be the customer of an 
optical transport network. 
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Service: A network operator delivers one or more services to a 
customer. A service in the context of this document (sometimes 
called a Network Service) is some form of connectivity between 
customer sites and the Internet or between customer sites across 
the network operator’s network and across the Internet. However, 
a distinction should be drawn between the parameters that describe 
a service as included in a customer service model (see the 
definition of this term, below) and a Service Level Agreement 
(SLA), as discussed in Sections 5 and 7.2. 


A service may be limited to simple connectivity (such as IP-based 
Internet access), may be a tunnel (such as a virtual circuit), or 
may involve more complex connectivity (such as in a multisite 
virtual private network). Services may be further enhanced by 
additional functions providing security, load balancing, 
accounting, and so forth. Additionally, services usually include 
guarantees of quality, throughput, and fault reporting. 


This document makes a distinction between a service as delivered 
to a customer (that is, the service as discussed on the interface 
between a customer and the network operator) and the service as 
realized within the network (as described in [RFC8199]). This 
distinction is discussed further in Section 6. 


Readers may also refer to [RFC7297] for an example of how an IP 
connectivity service may be characterized. 


Data Model: The information model (IM) and data model (DM) concepts 
are described in [RFC3444]. That document defines a data model by 
contrasting it with the definition of an IM as follows: 


The main purpose of an IM is to model managed objects at a 
conceptual level, independent of any specific implementations 
or protocols used to transport the data. The degree of 
specificity (or detail) of the abstractions defined in the IM 
depends on the modeling needs of its designers. In order to 
make the overall design as clear as possible, an IM should hide 
all protocol and implementation details. Another important 
characteristic of an IM is that it defines relationships 
between managed objects. 


DMs, conversely, are defined at a lower level of abstraction 
and include many details. They are intended for implementors 


and include protocol-specific constructs. 


As mentioned in Section 1, this document also uses the terms "data 
model" and "YANG module" as defined in [RFC7950]. 
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Service Model: A service model is a specific type of data model. It 
describes a service and the parameters of the service ina 
portable way that can be used uniformly and independent of the 
equipment and operating environment. The service model may be 
divided into the two following categories: 


Customer Service Model: A customer service model is used to 
describe a service as offered or delivered to a customer by a 


network operator as shown in Figure 1. It can be used by a 
human (via a user interface such as a GUI, web form, or 
Command-Line Interface (CLI)) or by software to configure or 


request a service and may equally be consumed by a human (such 
as via an order fulfillment system) or by a software component. 
Such models are sometimes referred to simply as "service 
models" [RFC8049]. A customer service model is expressed in a 
YANG module as a core set of parameters that are common across 
network operators: additional features that are specific to the 
offerings of individual network operators would be defined in 
extensions or augmentations of the module. Except where 
specific technology details are directly pertinent to the 
customer (such as encapsulations or mechanisms applied on 
access links), customer service models are technology agnostic 
so that the customer does not have influence over or knowledge 
of how the network operator engineers the service. 


An example of where such details are relevant to the customer 
is when they describe the behavior or interactions on the 
interface between the equipment at the customer site (often 
referred to as the Customer Edge or CE equipment) and the 
equipment at the network operator’s site (usually referred to 
as the Provider Edge or PE equipment). 


Service Delivery Model: A service delivery model is used by a 
network operator to define and manage how a service is 
engineered in the network. It can be used by a human operator 
(such as via a management station) or by a software tool to 
instruct network components. The YANG modules that encode such 
models are sometimes referred to as "network service YANG 
modules" [RFC8199] and are consumed by "external systems" such 
as an Operations Support System (OSS). A service delivery 
module is expressed as a core set of parameters that are common 
across a network type and technology: additional features that 
are specific to the configuration of individual vendor 
equipment or proprietary protocols would be defined in 
extensions or augmentations of the module. Service delivery 
modules include technology-specific modules. 
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The distinction between a customer service model and a service 
delivery model needs to be clarified. The modules that encode a 
customer service model are not used to directly configure network 
devices, protocols, or functions: it is not something that is sent 
to network devices (i.e., routers or switches) for processing. 
Equally, the modules that encode a customer service model do not 
describe how a network operator realizes and delivers the service 
described by the module. This distinction is discussed further in 
later sections. 


3. Using Service Models 


As already indicated, customer service models are used on the 
interface between customers and network operators. This is shown in 
Figure 1. 


The language in which a customer service model is described is a 
choice for whoever specifies the model. The IETF uses the YANG data 
modeling language defined in [RFC6020]. 


The encoding and communication protocol used to exchange a customer 
service model between the customer and network operator is specific 
to deployment and implementation. The IETF has standardized the 
NETCONF protocol [RFC6241] and the RESTCONF protocol [RFC8040] for 
interactions "on the wire" between software components with data 
encoded in XML or JSON. However, co-located software components 
might use an internal API, while systems with more direct human 
interactions might use web pages or even paper forms. Where direct 
human interaction comes into play, interface interactions may be 
realized via business practices that may introduce some margin of 
error, thus raising the priority for automated, deterministic 
interfaces. 


TRS RT RN T Customer Ba pe A 
| | Service Model | | 


Figure 1: The Customer Service Models Used on the Interface between 
Customers and Network Operators 


How a network operator processes a customer’s service request when 
described with a customer service model depends on the commercial and 
operational tools, processes, and policies used by the network 
operator. These may vary considerably from one network operator to 
another. 
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However, the intent is that the network operator maps the service 
request into configuration and operational parameters that control 
one or more networks to deliver the requested services. That means 
that the network operator (or software run by the network operator) 
takes the information in the customer service model and determines 
how to deliver the service by enabling and configuring network 
protocols and devices. They may achieve this by constructing service 
delivery models and passing them to network orchestrators or 
controllers. The use of standard customer service models eases 
service delivery by means of automation. 


3.1. Practical Considerations 


The practicality of customer service models has been repeatedly 
debated. It has been suggested that network operators have radically 
different business models and widely diverse commercial offerings, 
which makes a common customer service model impractical. However, 
L3SM [RFC8049] results from the consensus of multiple individuals 
working at network operators and offers a common core of service 
options that can be augmented according to the needs of individual 
network operators. 


It has also been suggested that there should be a single, base 
customer service module, and that details of individual services 
should be offered as extensions or augmentations of this. It is 
quite possible that a number of service parameters (such as the 
identity and postal address of a customer) will be common, and it 
would be a mistake to define them multiple times (once in each 
customer service model). However, the distinction between a ’module’ 
and a ’model’ should be considered at this point: modules are how the 
data for models is logically broken out and documented, especially 
for reuse in multiple models. 


4. Service Models in an SDN Context 


In an SDN system, the management of network resources and protocols 
is performed by software systems that determine how best to utilize 
the network. Figure 2 shows a sample architectural view of an SDN 
system where network elements are programmed by a component called an 
"SDN controller" (or "controller" for short) and where controllers 
are instructed by an orchestrator that has a wider view of the whole 
of, or part of, a network. The internal organization of an SDN 
control plane is specific to deployment. 
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| Orchestrator | 
Controller | Controller | Controller 
| | | | 
| Network | | Network | | Network | | Network | 
| Element | | Element | | Element | | Element | 


Figure 2: A Sample SDN Architecture 


A customer's service request is (or should be) technology agnostic. 
That is, a customer is unaware of the technology that the network 
operator has available to deliver the service, so the customer does 
not make requests specific to the underlying technology but is 
limited to making requests specific to the service that is to be 
delivered. The orchestrator must map the service request to its 
view, and this mapping may include a choice of which networks and 
technologies to use depending on which service features have been 
requested. 


One implementation option to achieve this mapping is to split the 


orchestration function between a "Service Orchestrator" and a 
"Network Orchestrator" as shown in Figure 3. 
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Customer 
SSS Service ---------- 
Model 
Service <-------- >| Customer 
| Orchestrator | (a) | | 
| ee 
E (6) a 
(b) Do epaian |Application| 
: | BSS/oss | 
Service Delivery 
Model 
Network | | Network 
| Orchestrator |o] Orchestrator | 
| | | | 
Network Configuration 
Model 
| | | | | | | 
| Controller | | Controller | | Controller | | Controller | 
| | il i | 
Device 
Configuration 
Model 
Network Network Network Network Network 
Element Element Element Element Element 


Figure 3: An Example SDN Architecture with a Service Orchestrator 


Figure 3 also shows where different data models might be applied 
within the architecture. The device configuration models are used by 
a controller to set parameters on an individual network element. The 
network configuration models are used by a network orchestrator to 
instruct controllers (which may each be responsible for multiple 
network elements) how to configure parts of a network. 
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The following examples illustrate the split between control 
components that expose a "service interface" that is present in many 
figures that show extended SDN architectures: 


o Figure 1 of [RFC7426] shows a separation of the "Application 
Plane", the "Network Services Abstraction Layer (NSAL)", and the 
"Control Plane". It marks the "Service Interface" as situated 
between the NSAL and the control plane. 


o Figure 1 of [RFC7491] shows an interface between an "Application 
Service Coordinator" and an "Application-Based Network Operations 
Controller". 


o Figure 1 of [RFC8199] shows an interface from an OSS or a Business 
Support System (BSS) that is expressed in "Network Service YANG 
Modules". 


This can all lead to some confusion around the definition of a 
"service interface" and a "service model". Some previous literature 
considers the interface northbound of the network orchestrator 
(labeled "(b)" in Figure 3) to be a "service interface" used by an 
application, but the service described at this interface is network 
centric and is aware of many features, such as topology, technology, 
and operator policy. Thus, we make a distinction between this type 
of service interface and the more abstract service interface (labeled 
"(a)" in Figure 3) where the service is described by a service model 
and the interaction is between the customer and network operator. 
Further discussion of this point is provided in Section 5. 


5. Possible Causes of Confusion 


In discussing service models, there are several possible causes of 
confusion: 


o The services we are discussing are connectivity services provided 
by network operators to customers; the services are achieved by 
manipulating the network resources of the operator’s network. 
This is a completely different thing to "Foo as a Service" (for 
example, Storage as a Service (SaaS)) where a service provider 
offers reachability to a value-added service that is provided at 
some location in the network using other resources (compute, 
storage, ...) that are not part of the network itself. The 
confusion arises not only because of the use of the word "service" 
in both cases, but also because network operators may offer both 
types of service to their customers. 
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o Network operation is normally out of scope in the discussion of 
services between a network operator and a customer. That means 
that the customer service model does not reveal to the customer 
anything about how the network operator delivers the service, nor 
does the model expose details of technology or network resources 
used to provide the service (all of these details could, in any 
case, be considered security vulnerabilities). For example, in 
the simple case of point-to-point virtual link connectivity 
provided by a network tunnel (such as an MPLS pseudowire), the 
network operator does not expose the path through the network that 
the tunnel follows. Of course, this does not preclude the network 
operator from taking guidance from the customer (such as to avoid 
routing traffic through a particular country) or from disclosing 
specific details (such as might be revealed by a route trace), but 
these are not standard features of the service as described in the 
customer service model. 


o The network operator may use further data models (service delivery 
models) that help to describe how the service is realized in the 
network. These models might be used on the interface between the 
service orchestrator and the network orchestrator, as shown in 
Figure 3, and might include many of the pieces of information from 
the customer service model alongside protocol parameters and 
device configuration information. [RFC8199] also terms these data 
models as "service models" and encodes them as "Network Service 
YANG Modules"; a comparison is provided in Section 6.1. It is 
important that the service orchestrator be able to map from a 
customer service model to these service delivery models, but they 
are not the same thing. 


o Commercial terms (such as "cost per byte", "cost per minute", and 
"scoped by quality and type of service", as well as terms related 
to payment) are generally not a good subject for standardization. 
It is possible that some network operators will enhance standard 
customer service models to include commercial information, but the 
way this is done is likely to vary widely between network 
operators. Thus, this feature is out of scope for standardized 
customer service models. 


o SLAs have a high degree of overlap with the definition of services 
present in customer service models. Requests for specific 
bandwidth, for example, might be present in a customer service 
model, and agreement to deliver a service is a commitment to the 
description of the service in the customer service model. 

However, SLAs typically include a number of fine-grained details 
about how services are allowed to vary, by how much, and how 
often. SLAs are also linked to commercial terms with penalties 
and so forth and thus are also not good topics for 
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standardization. As with commercial terms, it is expected that 
some network operators will enhance standard customer service 
models to include SLA parameters either using their own work or 
depending on material from standards bodies that specialize in 
this topic, but this feature is out of scope for the IETF’s 
customer service models. 


If a network operator chooses to express an SLA using a data 
model, that model might be referenced as an extension or an 
augmentation of the customer service model. 


6. Comparison with Other Work 


Other work has classified YANG modules, produced parallel 
architectures, and developed a range of YANG modules. This section 
briefly examines that other work and shows how it fits with the 
description of service models introduced in this document. 


6.1. Comparison with Network Service Models 


As previously noted, [RFC8199] provides a classification of YANG 
modules. It introduces the term "Network Service YANG Module" to 
identify the type of module used to "describe the configuration, 
state data, operations, and notifications of abstract representations 
of services implemented on one or multiple network elements." These 
modules are used to construct the service delivery models as 
described in this document; that is, they are the modules used on the 
interface between the service orchestrator or OSS/BSS and the network 
orchestrator, as shown in Figure 3. 


Figure 1 of [RFC8199] can be modified to make this more clear and to 
include an additional example of a Network Service YANG module, as 
shown in Figure 4. As can be seen, the highest classification of 
modules collects those that are used to deliver operations support 
and business support. These might be consumed by an Operations 
Support System (OSS) or a Business Support System (BSS), anda 
service orchestrator may form part of an OSS/BSS or may be a separate 
component. This highest layer in the figure is divided into the 
customer service modules that are used to describe services to a 
customer as discussed in this document, and other modules that 
describe further OSS/BSS functions such as billing and SLAs. 
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tan + tan + 
| | | | 
| Customer Service | | Other 
| YANG Modules | | Operations Support | 
| | | and | 
{===SS= + $=SS=S= + Business Support 
| | | | | | YANG Modules 
| | L2sm | | L3sm |_| | | 
| | | | | | | | 
[ n teat || | 
| | | | 
hesSo Ces SSeS oS eS SSeS + fa SSeS eae SSS SHS Saas + 


4+------------ + +------------ +  +------------- +  +------------ + 
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | 
eee eee T seamen Ay Senos E seen : 
Key: 


EVPN: Ethernet Virtual Private Network 

L2SM: Layer 2 Virtual Private Network Service Model 
L2VPN: Layer 2 Virtual Private Network 

L3SM: Layer 3 Virtual Private Network Service Model 
L3VPN: Layer 3 Virtual Private Network 

VPLS: Virtual Private LAN Service 

VPWS: Virtual Private Wire Service 


Figure 4: YANG Module Abstraction Layers Showing 
Customer Service Modules 
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6.2. Service Delivery and Network Element Model Work 


A number of IETF working groups are developing YANG modules related 
to services. These models focus on how the network operator 
configures the network through protocols and devices to deliver a 
service. Some of these models are classified as network service 
delivery models (also called service delivery models or network 
configuration models depending on the level at which they are 
pitched), while others have details that are related to specific 
element configuration and so are classed as network element models 


(also called device models). 
A sample set of these models is listed here: 


(0) [BGP-L3VPN-YANG] defines a YANG module that can be used to 
configure and manage BGP L3VPNs. 


o [L2VPN-YANG] documents a data model that is expected to be used by 
the management tools run by the network operators in order to 
manage and monitor the network resources that they use to deliver 
L2VPN services. 


o [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN 
service. 
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-3. Customer Service Model Work 


Several initiatives within the IETF are developing customer service 
models. The L3SM presents the L3VPN service, as described by a 
network operator, to a customer. Figure 5, which is reproduced from 
[RFC8049], shows that the L3SM is a customer service model as 


described in this document. 


L3VPN-SVC 
MODEL 
| 
4+------------------ + 4+----- + 
| Orchestration | < --- > | oss 
4+------------------ + 4+----- + 
| | 
4+---------------- + 
Config manager | 
+---------------- + | 
| | 
| Netconf/CLI .. 
| 
4------------------------------------------------ + 
Network 


Figure 5: The L3SM Service Architecture 


A Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE]. 
That model’s usage is described as in Figure 6, which is a 
reproduction of Figure 5 from that document. As can be seen, the 
L2SM is a customer service model as described in this document. 
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| 
L2VPN | 
Service | 
Model | 
| 
| Service Orchestration 
| 
| Service S a ian ant ao cman a + 
| Delivery +------ > | Application | 
| Model | | BSS/oss | 
| v +------------- + 
| Network Orchestration | 
| | 
$---------------- + | 
Config manager | 
PSROTSS eaae + Device 


Network 
Figure 6: The L2SM Service Architecture 
6.4. The MEF Architecture 


The MEF Forum (MEF) has developed an architecture for network 
management and operation. It is documented as the Lifecycle Service 
Orchestration (LSO) Reference Architecture and is illustrated in 
Figure 2 of [MEF-55]. 


The work of the MEF embraces all aspects of Lifecycle Service 
Orchestration, including billing, SLAs, order management, and 
lifecycle management. The IETF’s work on service models is typically 
smaller and offers a simple, self-contained service YANG module. 

This does not invalidate either approach: it only observes that they 
are different approaches. 
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Further Concepts 

This section introduces a few further, more advanced concepts. 
Technology Agnostic 

Service models should generally be technology agnostic. That is to 
say, the customer should not care how the service is provided so long 
as the service is delivered. 

However, some technologies reach to the customer site and impact the 


type of service delivered. Such features do need to be described in 
the service model. 


Two examples are as follows: 


o The data passed between customer equipment and network operator 
equipment will be encapsulated in a specific way, and that data- 
plane type forms part of the service. 


o Protocols that are run between customer equipment and network 
operator equipment (for example, Operations, Administration, and 
Maintenance (OAM) protocols, protocols for discovery, or protocols 
for exchanging routing information) need to be selected and 
configured as part of the service description. 


Relationship to Policy 


Policy appears as a crucial function in many places during network 
orchestration. A service orchestrator will, for example, apply the 
network operator's policies to determine how to provide a service for 
a particular customer (possibly considering commercial terms). 
However, the policies within a service model are limited to those 
over which a customer has direct influence and that are acted on by 
the network operator. 


The policies that express desired behavior of services on occurrence 
of specific events are close to SLA definitions: they should only be 
included in the base service model where they are common offerings of 
all network operators. Policies that describe which person working 
for a customer may request or modify services (that is, 
authorization) are close to commercial terms: they, too, should only 
be included in the base service model where they are common offerings 
of all network operators. 


As with commercial terms and SLAs discussed in Section 5, it is 


expected that some network operators will enhance standard customer 
service models to include policy parameters either using their own 
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work or depending on specific policy models built in the IETF or 
other standards bodies. 


Nevertheless, policy is so important that all service models should 
be designed to be easily extensible to allow policy components to be 
added and associated with services as needed. 


7.3. Operator-Specific Features 


7.4. 


Wu, 


When work on the L3SM was started, there was some doubt as to whether 
network operators would be able to agree on a common description of 
the services that they offer to their customers because, in a 
competitive environment, each markets the services in a different way 
with different additional features. However, the working group was 
able to agree on a core set of features that multiple network 
operators were willing to consider as "common". They also understood 
that, should an individual network operator want to describe 
additional features (operator-specific features), they could do so by 
extending or augmenting the L3SM model. 


Thus, when a basic description of a core service is agreed upon and 
documented in a service model, it is important that that model be 
easily extended or augmented by each network operator so that the 
standardized model can be used in a common way and only the operator- 
specific features be varied from one environment to another. 


Supporting Multiple Services 


Network operators will, in general, offer many different services to 
their customers. Each would normally be the subject of a separate 
service model. 


Whether each service model is handled by a specialized service 
orchestrator that is able to provide tuned behavior for a specific 
service, or whether all service models are handled by a single 
service orchestrator, is an implementation and deployment choice. 


It is expected that, over time, certain elements of the service 
models will be seen to repeat in each model. An example of such an 
element is the postal address of the customer. 


It is anticipated that, while access to such information from each 
service model is important, the data will be described in its own 
module and may form part of the service model either by inclusion or 
by index. 
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8. 
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Security Considerations 


The interface between customer and service provider is a commercial 
interface, and it needs to be subject to appropriate confidentiality. 
Additionally, knowledge of what services are provided to a customer 
or delivered by a network operator may supply information that can be 
used in a variety of security attacks. The service model itself will 
expose security-related parameters for the specific service where the 
related function is available to the customer. 


Clearly, the ability to modify information exchanges between customer 
and network operator may result in bogus requests, unwarranted 
billing, and false expectations. Furthermore, in an automated 
system, modifications to service requests or the injection of bogus 
requests may lead to attacks on the network and delivery of customer 
traffic to the wrong place. 


Therefore, it is important that the protocol interface used to 
exchange service request information between customer and network 
operator is subject to authorization, authentication, and encryption. 
Clearly, the level of abstraction provided by a service model 
protects the operator from unwarranted visibility into their network, 
and additional protection is provided by the fact that how the 
service is delivered is entirely up to the operator. 


Equally, all external interfaces, such as any of those between the 
functional components in Figure 3, need to be correctly secured. 
This document discusses modeling the information, not how it is 
exchanged. 


Manageability Considerations 


This whole document discusses issues related to network management 
and control. 


It is important to observe that automated service provisioning 
resulting from use of a customer service model may result in rapid 
and significant changes in traffic load within a network and that 
that might have an effect on other services carried in a network. 


It is expected, therefore, that a service-orchestration component has 
awareness of other service commitments, that the network- 
orchestration component will not commit network resources to fulfill 
a service unless doing so is appropriate, and that a feedback loop 
will be provided to report on degradation of the network that will 
impact the service. 


et al. Informational [Page 20] 


RFC 8309 Service Models Explained January 2018 


10. 


TI 


11 


11 


Wu, 


The operational state of a service does not form part of a customer 
service model. However, it is likely that a network operator may 
want to report some state information about various components of the 
service and that could be achieved through extensions to the core 
service model, just as SLA extensions could be made as described in 
Section 5. 


IANA Considerations 


This document does not require any IANA actions. 
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